The diagnostics_channel subscriber is deferred via a microtask. This means node-redis >=5.12.0 operations performed immediately after Sentry.init() (in the same synchronous tick) can run before the subscriber is attached and will not be traced. Consider hooking this up from the OpenTelemetry init path (after the context manager is registered) or otherwise ensuring subscription happens synchronously before user code continues.

This PR adds a new diagnostics_channel-based instrumentation path, but there are no unit tests covering span creation/end, error handling, or that the responseHook is invoked for command events. Since this package already has Redis tracing tests under packages/node/test/integrations/tracing/redis, it would be good to add a focused test suite for subscribeRedisDiagnosticChannels() using node:diagnostics_channel tracing channels.

l/q: Are these types also vendored? If so it might be nicer if they live in the vendored folder

Not vendored from OTEL. the those are exported by redis, shame we can't use it as a dev dep here.

m: I think it would make sense to add 2 tests. One for redis 5 with tracing channels and another without them. Then we would know if we break something.

There are subtle differences between span counts with 5.12 and <5.12 as a result of some decisions in the redis tracing channel PR.

But yea we should have both to make sure we capture correctly.

q: Would this work the same with CJS and ESM in Node? I wonder if there is a better way, than defer it to the next tick, like a "afterSetup" hook or so

Yea, it works the same. We have an afterAllSetup but that could be much later than we like, or too early. I have not tried tbh.

Let me give afterAllSetup a go.

Command error causes response hook on ended span

Medium Severity

Per the Node.js TracingChannel contract, when a traced promise rejects, both the error and asyncEnd events fire (in that order). The error handler sets the error status and ends the span, but then asyncEnd still runs runResponseHook on the already-ended span with a potentially undefined data.result, and calls span.end() again. The asyncEnd handler lacks a guard against the error-already-handled case, so cacheResponseHook may incorrectly set cache.hit: false (from calculateCacheItemSize(undefined) returning 0) on error spans.

 

^{Reviewed by Cursor Bugbot for commit 992feac. Configure here.}

DC error handlers miss recordException unlike IITM path

Medium Severity

The error handlers in all three DC channel subscribers (command, batch, connect) set the span status but don't call span.recordException(data.error). The corresponding IITM vendored instrumentation error paths (e.g., _endSpanWithResponse and the connect .catch handler) all call span.recordException(error) before setting status. This means redis error spans from the DC path (>= 5.12.0) carry less diagnostic detail than equivalent spans from the IITM path (< 5.12.0).

 

^{Reviewed by Cursor Bugbot for commit 5e6ea30. Configure here.}

Preload path permanently breaks DC context propagation

Medium Severity

When preloadOpenTelemetry is used (via --require), instrumentRedis() runs and schedules the DC subscription via Promise.resolve().then(). The microtask fires before the main module calls init(), so subscribeRedisDiagnosticChannels runs before the OTel context manager is set up. The tracingChannel helper falls back to returning the channel without bindStore (no context propagation), and sets subscribed = true. When init() later calls instrumentRedis() again (from setupOnce), the second microtask sees subscribed === true and exits early — the channels are never re-subscribed with proper context propagation. For redis >= 5.12 (where IITM is gated off), this results in orphaned spans without correct parent-child relationships.

 

^{Reviewed by Cursor Bugbot for commit 340e44a. Configure here.}